Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 6453 - Fix memory leaks in entryrdn #6455

Merged
merged 1 commit into from
Jan 14, 2025

Conversation

mreynolds389
Copy link
Contributor

@mreynolds389 mreynolds389 commented Dec 19, 2024

Description:

We leak memory when processing long DN's (mdb). We have to loop over long DN's and on each pass we leak the previous rdn element. In the tombstone case we just need to free the current childelem

Relates: #6453

Reviewed by: ?

@@ -1570,12 +1576,15 @@ _entryrdn_get_elem(entryrdn_db_ctx_t *ctx,
key->data, data->size, data->ulen, rc);
}
_ENTRYRDN_DEBUG_GOTO_BAIL();
slapi_ch_free((void**)elem);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will prevent the log of the rdn with the error
slapi_log_err(SLAPI_LOG_TRACE, "_entryrdn_get_elem", "<-- _entryrdn_get_elem (elem rdn=%s) rc=%d\n",
RDN_ADDR(elem), rc);
IMHO we should rather call if (rc) { slapi_ch_free((void
)elem); } after login the error in the bail section.

@@ -1695,12 +1711,18 @@ _entryrdn_get_tombstone_elem(entryrdn_db_ctx_t *ctx,
if (0 == strcmp(comma + 1, slapi_rdn_get_nrdn(srdn))) {
/* found and done */
_entryrdn_dup_rdn_elem((const void *)dataret.data, elem);
if (RDN_IS_REDIRECT(childelem)) {
slapi_ch_free((void **)&childelem);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sounds suspicious because childelem is an array elems ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sounds suspicious because childelem is an array elems ...

It fixes the leak. Note childelem and dataret.data point to the same address. I just chose to use childelem.

rc = dblayer_cursor_op(&ctx->cursor, dbop, key, data);
elem_data = data->data; /* save pointer to data so we can free it on a retry */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would not be slapi_ch_free((void**)elem); sufficient ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No because elem ptr is changed after we grab the original ptr address (when a retry occurs for a long rdn). So we need to free the previous value (elem_data). I'm reworking the variable name to be "prev_elem_data" so it's more clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH this was a really tricky set of leaks to fix. Took me a long time to finalize the fix.

Comment on lines 1550 to 1570
if (*elem) {
/* free the previous elem data */
slapi_ch_free((void**)&prev_elem_data);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we also need to check and free it at the bail: section

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we also need to check and free it at the bail: section

Maybe :-) Like I said this code is a bit tricky when it comes to handling long DN's vs not long DN's. I'll try and force some failures and see what happens...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe :-) Like I said this code is a bit tricky when it comes to handling long DN's vs not long DN's. I'll try and force some failures and see what happens...
That is a bit worrisome: I have the feeling that neither of us really understand the full impact of this change.
(I certainly don't ! 😦 )

My gut feeling is that things should not be so tricky.
Either I missed something when designing that code (quite possible as long dn handling was done as an afterthought) or we are not freeing Redirect rdn at the right place. (I wonder if in _entryrdn_resolve_redirect

         if (canfree) {
            slapi_ch_free((void**)elem);
        }

should not be moved around the end of the function (so that the redirect key get also freed in error case)
Or maybe the canfree flag is not set properly when calling _entryrdn_resolve_redirect ...

Description:

We leak memory when processing long DN's (mdb).  We have to loop over
long DN's and on each pass we leak the previous rdn element. In the
tombstone case we just need to free the current childelem

Relates: //github.com/389ds/issues/6453

Reviewed by: progier & spichugi(Thanks!!)
@mreynolds389
Copy link
Contributor Author

@progier389 @droideck ok I have revised the fix after forcing failures at all the failure points. This is did expose a flaw in the last patch (minor), but it allowed for a slightly more concise fix. This is ready for review now.

Copy link
Member

@droideck droideck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!
I'll leave the final check to @progier389 though, as he's more proficient with the area.

@mreynolds389
Copy link
Contributor Author

Looks good to me! I'll leave the final check to @progier389 though, as he's more proficient with the area.

@progier389 kind reminder to review please :-)

Copy link
Contributor

@progier389 progier389 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mreynolds389 mreynolds389 merged commit 9e09235 into 389ds:main Jan 14, 2025
195 of 199 checks passed
@mreynolds389 mreynolds389 deleted the entryrdn_leaks branch January 14, 2025 16:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants